home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000515_connolly@pixel.convex.com _Fri Jan 8 00:59:21 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  10KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA25970; Fri, 8 Jan 93 00:59:21 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA11465; Fri, 8 Jan 1993 01:14:18 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA29874; Thu, 7 Jan 93 18:13:48 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA06638; Thu, 7 Jan 93 18:13:46 -0600
  10. Message-Id: <9301080013.AA06638@pixel.convex.com>
  11. To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: dealing with new-lines 
  14. In-Reply-To: Your message of "Thu, 07 Jan 93 16:27:50 EST."
  15.              <9301072127.AA07870@soccer.cis.ohio-state.edu> 
  16. Date: Thu, 07 Jan 93 18:13:46 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >How should browsers deal with new-lines, and where can html-generators
  21. >put in new-lines?
  22.  
  23. Darn good question. Your approach appears to have the correct
  24. results, but I'm not sure it's practical for many implementations
  25. (global search-and-replace operations are inconvenient for
  26. sequential processing models), and it certainly isn't a healthy
  27. way to think about SGML documents.
  28.  
  29. The way to think about SGML documents, IMHO, is this: the sequence
  30. of characters comprising an SGML document are presented to an
  31. SGML parser, which parses the markup from the data and passes
  32. the "results" to the processing application.
  33.  
  34. [Much of this is covered in
  35. http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/921203/Text.html
  36. and what isn't there should be, but bear with me...]
  37.  
  38. So many of the details of the syntax of SGML are invisible to
  39. the processing application: the fact that <>'s delimit tags
  40. in stead of {}'s for example.
  41.  
  42. The information delivered to the application by the parser
  43. is called the Element Structure Information Set. It contains
  44. things like tags, attributes, attribute values, and data
  45. characters.
  46.  
  47. So there are two questions, to my mind:
  48. 1. How does the SGML parser treat newlines?
  49. 2. How does the WWW processing application treat newlines?
  50.  
  51. Question 1 is answered by the SGML standard. Question 2
  52. is for us to decide.
  53.  
  54. SGML defines several types of content, which determine
  55. the kinds of markup that are recognized inside an element.
  56. The simplest is EMPTY, for example:
  57.  
  58. <!ELEMENT P - O EMPTY>
  59.  
  60. When you see a P start tag, you know there is no content,
  61. and you assume that a P tag follows, effectively.
  62.  
  63. The next simplest is CDATA, for example:
  64.  
  65. <!ELEMENT TITLE - - CDATA>
  66.  
  67. When you parse the content of a TITLE element, the only
  68. thing you look for is an end tag. Everything else is
  69. reported by the SGML parser as data characters.
  70.  
  71. Then there is RCDATA, which is just like CDATA, except
  72. for character and entity references.
  73.  
  74. The most common content type is MIXED, where all kinds
  75. of markup are recognized: tags, entities, as well as data.
  76. For example:
  77.  
  78. <!ELEMENT ADDRESS - - (#PCDATA|A|P)>
  79.  
  80. The parser should report start tags, end tags, entities,
  81. and data inside an ADDRESS element.
  82.  
  83. Then there is ELEMENT content, where only tags are
  84. recognized, for example:
  85.  
  86. <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID?)>
  87.  
  88. The parser will report any data inside a HEAD element
  89. as an error. But [and this is the reason I went through
  90. this whole excercise] whitespace is ignored between
  91. tags in element content. So the text:
  92.  
  93. <head>
  94. <title>sample</title>
  95. </head>
  96.  
  97. will be reported to the application by the parser as
  98. a HEAD start tag,
  99. a TITLE start tag,
  100. the data string "sample",
  101. a TITLE close tag,
  102. and a HEAD close tag,
  103. whereas the text:
  104.  
  105. <address>
  106. <a HREF="#tim">Tim Berners-Lee</a>
  107. </address>
  108.  
  109. will be reported as
  110. an ADDRESS start tag,
  111. the data string "\n"
  112. an A start tag (with an HREF attribute and value),
  113. the data string "Tim Berners-Lee",
  114. the data string "\n"
  115. an A close tag,
  116. and an ADDRESS close tag.
  117.  
  118. [There's another content type called ANY, but it's just
  119. like MIXED for our purposes.]
  120.  
  121. >I spent quite a bit of time thinking about what is intuitively the right
  122. >way to do it, and I came up with this method.
  123. >
  124. >0. Convert all new-lines inside of tags to spaces.
  125.  
  126. Newlines inside tags are the responsibility of the
  127. SGML parser. I suggest you use the excellent sgmls
  128. parser to test your rules by trial and error, or
  129. consult the standard.
  130.  
  131. I have done both, and the results of my labors
  132. are available in libHTML. I have also done an elisp
  133. implementation, if anybody's interested.
  134.  
  135. The one tricky case is newlines inside attribute
  136. value literals, e.g.
  137.  
  138. <foo bar="12
  139. 3">
  140.  
  141. This one is a little tricky. SGML section 7.9.3 says:
  142.  
  143. "An attribute value literal is interpreted as an attribute value by
  144. replacing references within it, ignoring Ee and RS, and replacing RE
  145. or SEPCHAR with SPACE."
  146.  
  147. The reference concrete syntax assigns the conventional unix newline
  148. character, ASCII code 10, to the role of RS. So strictly speaking,
  149. it should be ignored, and the value of the attribute is "123".
  150.  
  151. On the other hand, the sgmls parser does a little behind-the-scenes
  152. magic on newlines. From the sgmls man page:
  153.  
  154.      An external entity resides in one or more files.  The entity
  155.      manager component of sgmls maps a sequence of files into an
  156.      entity in three sequential stages:
  157.  
  158.      1.   each carriage return character is turned into a non-
  159.           SGML character;
  160.  
  161.      2.   each newline character is turned into a record end
  162.           character, and at the same time a record start charac-
  163.           ter is inserted at the beginning of each line;
  164.  
  165.      3.   the files are concatenated.
  166.  
  167. [This sort of thing _does_ still conform to the SGML standard.
  168. You're allowed to do magic while assembling entities]
  169.  
  170. So using sgmls, the newline in this case would be treated as
  171. RE, and converted to SPACE, i.e. ASCII character 32, by the
  172. parser. So the value of the bar attribute is "12 3".
  173.  
  174. It's a question of how we construct SGML entities from HTML
  175. data streams.
  176.  
  177.  
  178. >1. For each tag NOT in
  179. >     <PRE> </PRE> <A> </A> <PLAINTEXT>
  180. >   remove ALL surrounding new-lines.
  181.  
  182. First, let's get one thing straight: the PLAINTEXT element as
  183. described by the original HTML documentation is not representable
  184. in SGML. For my purposes, I consider the HTML document to
  185. end at the <PLAINTEXT> tag, and I consider the rest of the
  186. data stream to be an RFC-822 message body or a MIME text/plain body,
  187. and not SGML at all.
  188.  
  189. Next, let's keep in mind that you can't do things like the following
  190. global substitition,
  191. s/\n+(<(H1|H2|ADDRESS...))>/$2/g;
  192. because it might find things that look like tags but aren't,
  193. for example
  194.  
  195. <foo bar="
  196. <H1>this is a little cooky, but nontheless legal and possible.">
  197.  
  198. But even if you're using a proper SGML parser, consider:
  199.  
  200. <H1>Here we go!
  201. <a href="#xyz">click here</a>
  202. There we went!
  203. </H1>
  204.  
  205. The parser will return an H1 start tag, and then the
  206. string "Here we go!\n". At this point, your rule doesn't
  207. tell me what to do with the newline. I have to get
  208. the next object before I decide.
  209.  
  210. Hmm... I guess that's reasonable. But I'd rather just pass all the
  211. data charcters on the the text formatter and let it figure all this out.
  212.  
  213. Do we want to specify rules for the text formatter? If so, we need to
  214. go beyond just newlines.  I see some data providers writing things
  215. like:
  216.  
  217. <H1>Here are some things to consider:</H1>
  218. <p>      thing one
  219. <p>      thing two
  220. <p>      thing three
  221.  
  222. The MidasWWW browser displays this as
  223.  
  224. Here are some things to consider:
  225. thing one
  226. thing two
  227. thing three
  228.  
  229. which I think is reasonable. The provider should either use
  230. <H1>Here are some things to consider</H1>
  231. <UL>
  232. <li>thing one
  233. <li>thing two
  234. <li>thing three
  235. </ul>
  236.  
  237. or at a minimum,
  238.  
  239. <H1>Here are some things to consider</H1>
  240. <PRE>
  241.      thing one
  242.      thing two
  243.      thing three
  244. </PRE>
  245.  
  246.  
  247. >2. For each tag in
  248. >     <PRE> <PLAINTEXT>
  249. >   remove ALL new-lines to left, and one new-line to the right.
  250.  
  251. Why remove one new-line to the right? Just for HTML source file aesthetics?
  252.  
  253. >If XMP and LISTING sections are being used, they would be treated the
  254. >same as PRE.
  255. >
  256. >Note that this converts new-lines around anchors into spaces UNLESS they
  257. >appear immediately at the beginning or end of some other element.
  258.  
  259. There are also some new elements that act like A: EM, CODE, SAMP, etc.
  260.  
  261. >If browsers use this method, it would allow html-generators to put in
  262. >new-lines all over the place for readability of HTML, without introducing
  263. >lots of annoying extra spaces in the output.  This is what seems like
  264. >the most useful thing to do, although I'm not sure it is "correct".
  265. >
  266. >So is it correct?  And are there any obvious flaws?
  267.  
  268. We have not specified the rules for typesetting elements other
  269. than XMP, LISTING, and PRE before now, so what you suggest is
  270. as correct as anything else.
  271.  
  272. I think it's important that we agree on how to typeset the <PRE>
  273. element. [And I think getting rid of the first newline after a <PRE>
  274. tag is a Bad Thing.]
  275.  
  276. It's not important to me that we agree how to typeset other elements.
  277. I'm inclined to give formatters great leeway with how they treat whitespace.
  278. I wouldn't mind at all if something like
  279.  
  280. <H1>testing 123</H1>
  281. foo       bar     blech        icky<a>wicky</a>
  282.  
  283.  
  284. woo
  285. <p>  abc defghi
  286. jhkl sldjkf sld        lsdjkf
  287.  
  288.  
  289. were typeset as:
  290.  
  291.     TESTING        123
  292.  
  293.     foo bar blech ickywicky woo
  294.  
  295.     abc defghi jhkl sldjkf sld lsdjkf
  296.  
  297. My point is: don't use whitespace to represent significant
  298. information except in the PRE elemnt. Use the tags that
  299. are defined to have significance.
  300.  
  301. Dan
  302.